The NoEstimates Hashtag
In Twitter, we use the convention of “hashtags” to connect a tweet with a theme or topic so that it is easy (or at least a bit easier) to search and find tweets for topics we want to follow.
Several people have blamed me for coining the “#NoEstimates” hashtag. It might be true – I’m not sure. It is possible that I was the first to use this hashtag for Software Development – a search of Twitter history on it shows that, as far as I can tell.
[UPDATE: I found the following post from Aslak Hellesøy – @aslak_hellesoy dated Feb 10, 2010 that used this hashtag
@obie at #speakerconf: “Velocity is important for budgeting”. Disagree. Measuring cycle time is a richer metric. #kanban #noestimates.]
SO… What is the Topic of the #NoEstimates Hashtag?
Here it is, as defined by me. Others probably have their own idea:
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.
I’ll probably modify this a bit over time – I put this together quickly as a starting point.
Also, A Word About Estimates
Estimates are typically and pervasively used in the decision-making process throughout software development organizations and efforts – both in “phased/waterfall” and “Agile” methodologies. They are ubiquitous – it is rare to find a project/organization/effort where it isn’t simply accepted that “we must have estimates – it is the only way”.
Additionally, for a long time I’ve been noticing that almost every training, book, conference session, article, or blog on “Agile” software development has a very heavy focus on estimating. I’m fine with important things taking a lot of our attention – they are important, after all. Are estimates that important?
I’ve also noticed over the years that many organizations have a number of dysfunctions in how estimates are handled, and the overall decision making process that depends on estimates. Have you noticed any dysfunctions?
So… I started doing “5 why sessions” or similar exercises at conferences and user groups, and other investigations into the reasons for this, and the dysfunctions that people have been experiencing. I also started discussing alternative ways to manage software development efforts without using estimates. I’ve been working without estimates for years for many decisions that are typically “estimate-driven” in software development management, and some people are interested in how to do this.
It’s important to ask ourselves questions such as: Do we really need estimates? Are they really that important? Are there options? Are there other ways to do things? Are there BETTER ways to do thing?
If we are willing to simply play the “devil’s advocate”, and imagine (or at least temporarily pretend) that perhaps there are better ways to make decisions, it can lead to more open thinking and clarity as to why we “believe the things we believe”. Why not question the things we hold so dearly?
There ya go! Have Fun!
Bob MacNeal:
Thanks for bringing up this discussion.
Developers need stories in the backlog. That’s it. They don’t need estimates. Estimates have little to no value to visioning or producing a software product. In my experience, estimates are mainly championed by people who make a living off of the illusion of control that numbers give managers.
Folks on the conference circuit love to blather on about estimation techniques. It all seems kind of silly to the producers. Real (hours) or fake (points), most developers either underestimate (because of hubris) or sandbag (so they can gold plate, learn new stuff, or surf the web). Either way, the illusion of control is just that – an illusion.
17 May 2013, 2:53 pmTom Howlett:
In the team I’ve been working with for the last 5 years we’ve spent less and less time on estimates to the point where we rarely do them. I think the reasons for this are:
1. Although the business thought they wanted to use estimates in the decision making process, it turned out that we ended up doing what our customers wanted the most anyway.
2. We control the time we spend on stories by deciding when to stop, varying how deep we go in a release.
3. We thought that the estimating process itself was a good time for the whole team to share ideas on a story, but it turns out its better to get the whole team together to share ideas regularly while working on the story not up front.
4. When we started explicitly expressing our confidence levels in our own estimates the business recognised how little value they have.
5. I think everyone recognised that estimating resulted in defensive behaviours as we made new discoveries about what was needed. Life without estimates is more collaborative.
Apart from removing waste, not doing estimates has a big advantage; it encourages customers/business owners to become more involved while the work in progress because they want to ensure they are getting good value. This means we get more feedback and they get to say when we’ve gone far enough with the story.
So yeah, I think you’re right there is real value in exploring not doing estimates in product development. I feel for from qualified from making a judgement in other peoples contexts although I applaud your efforts in encouraging people to explore alternative in their situation.
18 May 2013, 7:19 amTobias Mayer:
I’m certainly not in favor of estimating in order to make promises—and no matter which numeric system is used the numbers will either be gamed, and/or injected into some planning function, giving (as Bob points out, an illusion of control). All this is wasteful and rather meaningless.
I’m in favor of estimating as a starting point for conversation:
– This feels big, how do we break it down?
– This will cost a lot—what’s the value it’ll give?
– These things seem quick to do…
– I reckon I can get this done by Thursday.
– This is taking longer than we thought—can we simplify it?
– We can probably get something meaningful for release in about 3-4 weeks.
Software development, like all creative making envisions a desirable future state. As we work, we make guesses on aspects such as cost/time/value. We can call these guesses estimates, or assessments, or projections. The term isn’t important. The truth is: they are guesses. To not make any guesses feels unnatural and contrived to me. The purpose of estimation is not to make promises. It is merely one factor that can lead to more meaningful conversation.
Guessing about the future is a useful, and natural human behavior. We use experience, gut feel, history to improve the quality of our guesses. Perhaps as well as seeking ways not to estimate (a useful pursuit, for sure), we can also seek ways to make our estimation practices more meaningful.
18 May 2013, 11:15 amTobias Mayer:
Re your twitter response: “You provide a list of non-estimates in support of your idea of “estimates”.” Let me clarify:
– This feels big, how do we break it down?
This is a size estimate—relative size. “Big” must be relative to something, so assumes other items of work are being done by the same person/team that are smaller.
– This will cost a lot—what’s the value it’ll give?
This is a cost estimate, followed by a request for a value estimate. The two together determine if the work should progress.
– These things seem quick to do…
This is an effort estimate. We guess these things will not take much effort, and will be completed quickly.
– I reckon I can get this done by Thursday.
This is a time estimate. One presumes it follows a sizing estimate for the speaker to have some sense of how long it would take.
– This is taking longer than we thought—can we simplify it?
This is a re-estimation of size after the work has been started, and more is known.
– We can probably get something meaningful for release in about 3-4 weeks.
Again, a time estimation. If the date is important for some reason I’d recommend checking in regularly (weekly or less) to see if the estimate of 3-4 weeks continues to be realistic, and if not looking for ways to either narrow scope or reset the date.
These are just some of the ways people estimate. Estimate (vb): to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately. —dictionary.com
If you consider my examples non-estimates I’m interested to know the definition you are using when you use the #NoEstimtes tag. If it’s something like “to talk in detail about a large group of items, and and give them effort numbers which are then used to make commitments” (or some other refined meaning) then it may be helpful to be explicit. As it is now, the #NoEstimates movement is rather confusing, and seems to generate semantic disagreements rather than useful dialog on practices. Which is a shame.
18 May 2013, 5:26 pmEric Jacobson:
Woody,
I was just referred to your blog by a friend. Great stuff. Thanks for your contributions.
I’m caught up on your last maybe 6 posts. There seems to be a gap in your discussions: Kanban. Kanban has already solved the problem of making decisions based on estimates, right? Per my research, Kanban does not use estimates. Instead, “actual” cycle/lead times are measured. These actuals inform the future. I saw that you like to slice stories to smaller sizes and one of your comments suggested WIP. But if Kanban is the second most popular Agile methodology, and it doesn’t depend on estimates, why is it not discussed?
11 December 2013, 8:40 amWoody Z.:
Hello Eric,
Thanks for visiting my blog. Well… Measuring of “actuals” is fine I suppose. Many people seem to think that has meaning or some sort of use. If you have a use for that then do it. However, using them to “inform the future” means you are using the actuals to estimate work. Estimates are done many ways – and one way is to keep track of how long something takes, and then use that as a basis to calculate the time/cost/work needed for work that follows on.
I haven’t yet read anything about Kanban (with a capital K) that is of much interest to me in relation to the concept of estimates. That doesn’t mean it isn’t worth looking into, or experimenting with, or using. And it doesn’t mean that trolls should attack me for saying anything about Kanban. And I am not saying that there are lots of Kanban trolls… just hinting at it.
Anyway – What makes you think Kanban is an Agile methodology? The “main folks” in that realm seem to insist it is not. Perhaps I am mistaken about that?
19 December 2013, 11:34 amEric Jacobson:
Me again. Okay, new comment. New subject.
The reason I was referred to your blog is I’m trying to wean my Kanban team off Story Point estimates. I know, despite my prior post, this team is still doing story point estimates. Here is the main impediment to removing story point estimates. We put a reward system in place. If we delivered above a certain amount of story points last month (with no production bugs), the team gets a free half day off. Everybody loves this. It’s a treat to achieve it. The trouble is, once we remove story point estimates, we need a new way to measure relative success.
If we always had similar sized stories (we don’t), we could count stories delivered. What I really want to count is customer delight. I just don’t know how. I can’t send out a survey each month; the customers will start to hate me.
I’m diverging from your #NoEstimates topic. Nevertheless. Can you help?
11 December 2013, 8:51 amWoody Z.:
Hello Eric,
Thanks for visiting again. You are welcome back anytime you would like.
A reward system? Based on story points? Well… you probably don’t want to hear what I’ve got to say about that, but here is a hint: YIKES!
Besides the reward system, what are the story points for if you are simply measuring actual cost/time and using that to “inform the future”?
Cheers,
19 December 2013, 11:41 amWoody
Eric Jacobson:
Woody, I think you misread my question. You and I agree that basing a reward on story points is probably bad. That is why I am trying to replace it with a better practice.
What ideas can you provide? What is a better thing to base rewards on?
2 January 2014, 12:01 pmEric Jacobson:
“What makes you think Kanban is an Agile methodology? The “main folks” in that realm seem to insist it is not. Perhaps I am mistaken about that?”
Which folks are you referring to, Woody? Kanban certainly follows the Twelve Principles of Agile Software in the Agile Manifesto. Most Agile coaches and books I’ve encountered consider Kanban an agile methodology. Finally, my personal experiences on Scrum and Kanban teams tell me Kanban is perhaps more agile than Scrum (i.e., Kanban supports the Agile Manifesto even better than Scrum).
A rose by any other name would smell as sweet…
2 January 2014, 2:05 pmWoody Z.:
Hey Eric:
1. “Better thing to base rewards on”.
– What is the purpose of the “rewards”? If people are not being paid sufficiently then adjust their pay so they are. Again: Rewards? YIKES!
2. “Which folks”
I’ll leave that for you to search in your favorite search engine.
3 January 2014, 1:28 pmEric Jacobson:
Interesting idea to just pay people more. Modern experiments have shown, higher salaries don’t result in better job satisfaction. IMO, rewarding people for exceptional work, makes them feel appreciated and thus increases job satisfaction.
I liked your story about your favorite boss, at the garden center. My favorite boss would occasionally call me into his office and give me $100, saying “go take your wife out for a nice dinner, you did an exceptional job testing yesterday’s release”.
In my current job, as a manager, I can’t easily make budget decisions resulting in pay raises for entire project teams. However, I can provide other rewards, like paid time off. This has worked well, IMO. The reward is not the problem. It’s the measurement that informs the reward I’m trying to improve.
Anyway, I’m way off topic for the blog theme you’re interested in right now, so I think I’ll go fishing and find other advice. Thanks, Woody.
8 January 2014, 6:27 amWoody Z.:
Hello Eric: I am not saying “pay people more”. I am saying that if you are not paying your people sufficiently, you should fix that. I don’t think “modern experiments have shown” has any meaning. I think there is a lot on this topic that “proves” the exact opposite of what you say. I’ll leave it at this: If you are trying to find the right measurement to trigger a reward, you will get the behavior you are measuring for at the expense of other behaviors that are just as meaningful. There is so much written about this that it makes no sense for us to discuss it hear.
17 January 2014, 3:13 pmDavid Lowe:
Hi Eric & Woody, I know it’s off the topic of the post, but I’m with Woody that Kanban is not technically agile; it’s lean. But, anyone using Kanban would be unlikely to do anything out of line with the agile manifesto.
Woody, fascinating posts re no estimates. Cheers.
8 January 2014, 3:06 pmTim Ottinger:
Rewards don’t work like people think they do.
Clearly a lack of money is a motivator, so I agree about “pay enough” and Daniel Pink’s quoted research seems to agree.
Likewise, all I’ve found agrees that “Modern experiments have shown, higher salaries don’t result in better job satisfaction.” — most people after either winning the lottery or losing a limb are just about as happy a year later as a year before. Circumstances are not a long-term motivator (once you get past “enough to stop worrying about the money”).
Older than that is Scholtes’ work (quoted here:http://agileotter.blogspot.com/2015/04/bonus-for-productivity.html) which suggests that rewarding people who do knowledge work for performance is a losing proposition and a poor/insulting mental model.
Pink’s work seems also to suggest that pay for performance of cognitive tasks not only doesn’t help, but clearly makes things worse.
Mind you, for physical labor, basic operational work, rote work, etc, rewards work pretty much as you expect. It’s just in the realm beyond “rudimentary cognitive ability” that it goes all pear-shaped.
See: https://www.youtube.com/watch?v=u6XAPnuFjJc
Motivation is multi-causal and complex, but there are repeatable experiments and observations.
But that doesn’t tell us much about estimates… though this is becoming a long reply so I’ll stop here.
21 April 2015, 6:25 pm